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1.  Introduction 


The  transformation  of  the  U.S.  Army  toward  an  objeetive  foree  that  is  more  lethal,  survivable, 
sustainable,  and  responsive  to  worldwide  threats  will  inelude  robotie  systems.  The  Future 
Combat  System  (FCS)  and  Objeetive  Foree  Warrior  (OFW)  are  two  eritieal  initiatives  leading 
toward  the  Objeetive  Foree  that  will  inelude  robotie  systems.  The  U.S.  Army  Chief  of  Staff, 
General  Shinseki  stresses  that  soldiers  will  “remain  the  centerpieee  of  our  formations”  and  will 
be  the  “heart”  of  the  Objeetive  Force  (1).  The  U.S.  Army  Research  Laboratory  (ARL)  is 
developing  technology  that  supports  the  FCS  and  the  soldier-centric  OFW  initiatives.  For  OFW 
2010,  there  is  an  immediate  need  for  a  robotic  follower  within  the  next  2-3  years.  OFW  focuses 
on  extending  small  team  capabilities  without  overburdening  the  warrior  (this  will  include  robotic 
systems)  (2).  This  report  will  discuss  some  of  the  work  that  ARL  is  doing  with  the  Land  Warrior 
(LW)  program  and  the  OFW  Program. 

With  robots  being  ubiquitous  on  the  battlefield  of  the  future,  it  is  necessary  for  a  robotic 
architecture  that  will  encompass  many  of  the  aspects  of  the  interaction  between  soldiers  and 
robots.  The  system  design  presented  in  this  paper  takes  many  aspects  of  existing  hierarchical 
and  reactive  robotic  paradigms  (5)  and  existing  command  and  control  (C2)  applications  (such  as 
two-dimensional  [2-D]  and  three-dimensional  [3-D]  visualization)  to  create  a  hybrid  architecture 
that  is  usable  by  multiple  agent  teams,  as  well  as  soldiers  at  different  levels  to  control  the  robots 
on  the  battlefield. 

For  example,  a  team  of  n-robots  may  be  controlled  from  the  rear  by  a  few  soldiers  in  a  C2 
vehicle,  a  tactical  operations  center  (TOC),  or  from  another  part  of  the  world.  In  addition  to  the 
robots  on  the  ground,  soldiers  (wearing  LW  systems)  may  be  operating  in  the  same  area.  And,  it 
may  be  necessary,  desired,  or  required  for  the  soldiers  (presumably  light  forces  for  this  example) 
to  communicate  with  or  take  control  of  the  robots  operating  in  their  area.  In  order  to  accomplish 
this,  the  architecture  on  the  robot  must  be  compatible  with  the  rear  command  and  control  vehicle 
as  well  as  with  the  small  limited  computers  that  the  soldiers  may  be  wearing  or  have  with  them. 
Additionally,  the  robots  controlled  from  afar  may  carry  smaller  robots  that  are  specifically  more 
useful  to  ground  soldiers  and  may  deliver  smaller  robots  or  other  equipment  to  an  area.  This 
paper  will  address  in  more  detail,  the  system  design  that  incorporates  multiple  levels  of  control 
of  multiple  robots,  including  collaboration  between  robots  and  robots  acting  as  mother  ships  for 
other  robots  or  soldier’s  (Multi-function  Utility  Logistics  Equipment  [MULE]). 

This  report  also  discusses  several  experiments  in  which  1-3  robots  were  controlled  by  a  single 
operator  to  conduct  reconnaissance,  surveillance,  and  target  acquisition  (RSTA)  missions  to 
include  the  detection  of  acoustic  events,  namely  gunshots  and  other  loud  acoustic  events,  and 
conduct  surveillance  of  moving  targets  using  visible  and  infrared  (IR)  sensors.  Results  from  field 
experiments  conducted  at  Ft.  Knox,  KY  and  Ft.  Bragg,  NC  will  be  presented. 
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2.  System  Architecture 


The  system  arehitecture  presented  here  evolved  out  of  the  need  to  eontrol  multiple  robots  from 
multiple  eehelons.  As  discussed  previously,  robotic  systems  need  to  be  controlled  from  the  rear, 
or  perhaps  a  C2  vehicle.  In  order  to  accomplish  this,  we  tied  the  control  of  the  robots  to  our  2-D 
DII/COE  (or  Combat  Information  Processing  [CIP])  mapping  application  and  to  our  Virtual 
Geographical  Information  System  (VGIS)  3-D  visualization  application.  Both  of  these 
applications  have  been  widely  used  on  several  U.S.  Army  Intel  programs. 

Similarly,  we  needed  to  be  able  to  control  the  robots  from  the  individual  soldier.  The  soldier  can 
currently  control  the  robots  using  teleoperation  and  semi-autonomous  waypoint  navigation,  and 
in  the  future,  the  architecture  can  accommodate  fully  autonomous  robots.  The  system  supports 
multimodal  input  including  the  following:  text,  joystick,  speech,  and  waypoint  designation. 

This  leads  to  the  integration  with  the  LW  System.  We  integrated  thin-client  applications  onto  an 
LW  training  system  in  order  for  the  LW  System  to  control  multiple  robots.  By  adding  thin 
clients  to  the  LW  System,  we  are  able  to  take  advantage  of  the  processing  onboard  the  robot  and 
not  burden  the  limited  processing  capability  of  the  LW  System.  This  is  discussed  in  the  Lt.  Knox 
and  Lt.  Bragg  experiments.  We  demonstrated  this  control  from  a  Bradley  Lighting  Vehicle 
(Scout  Warrior),  and  from  a  light  infantry  soldier  wearing  only  an  LW  System. 

2.1  Software  Application  Architecture 

The  testbeds  ARL  is  using  for  the  research  presented  in  this  paper  are  commercial  off-the-shelf 
(COTS)  robotic  mobility  platforms  (ATRV-2,  Urban  Robot,  and  Packbot)  from  iRobot  (formerly 
IS  Robotics  and  Real  World  Interface  [RWI]).  The  robots  are  subsequently  outfitted  with  various 
sensors  such  as  an  acoustic  array,  visible  and  IR  cameras,  and  an  anemometer  meteorological 
sensor  and  include  the  ARL  robot  control  software  to  perform  the  RSTA  tasks. 

The  software  architecture  of  the  Robot  Team  Agent  follows  the  client/server  software  model 
approach.  It  is  a  message-based  and  modular  infrastructure  that  is  designed  to  provide  usability, 
flexibility,  interoperability,  and  scalability. 

The  ARL  Robot  Control  Software  package  is  a  defined  suite  of  software  modules  and  application 
programmer  interfaces  (API)  with  multithreaded  reconnect  capability,  using  pthreads  {4).  Some 
software  modules,  like  the  RobotAgent  and  the  LocationAgent  are  connected  to  the  robot  motors 
and  wheel  encoders  through  the  RWI  CORBA  2.0  compliant  hardware  servers  (5)  to  control  the 
robot  movement  and  to  inquire  the  robot  local  location  x,y.  Communication  between  the  ARL 
software  modules  is  based  on  the  ARL  dynamic  distributed  processing  infrastructure  using 
CIPNLT  and  the  Agent  Registry  services  (6). 


2.1,1  CIP  Interprocess  Communication 

The  Robotic  Control  Software  shares  the  same  common  networking  services  that  exist  within  the 
ARL  CIP  2-D  display  software  and  the  VGIS  3-D  display  software.  These  network  services 
provide  an  intertask  communications  protocol  to  isolate  applications  from  the  system  specific 
interprocess  communications.  The  network  is  logically  separated  into  three  layers:  CPU/Chassis, 
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Local  Area  Network  (LAN),  and  Wide  Area  Network  (WAN).  A  CPU/Chassis  consists  of  only 
one  logieal  CPU  and  a  baekplane  of  peripherals.  If  there  are  multiple  physieal  CPUs  available,  it 
is  assumed  that  the  operating  system  (OS)  will  make  this  transparent,  using  symmetrie 
multproeessing.  At  this  level,  the  intertask  eommunieations  is  implemented  using  Unix’s 
interproeess  eommunieations  (IPC)  standard.  A  LAN  consists  of  a  group  of  CPU/Chassis's 
logically  connected  by  ethernet  (TCP/IP).  A  WAN  eonsists  of  a  group  of  LANs  logieally 
eonneeted  by  various  physieal  media,  sueh  as  radio  frequeney  (RF)  links,  ethernet,  or  RS-232 
serial.  A  task  is  a  program  running  on  a  CPU/Chassis  partieipating  in  the  network.  Every  task 
has  a  unique  assigned  identifieation  number  (taskid)  defined  at  run  time.  Taskid’s  will  be  bound 
at  run  time  to  symbolie  names  (taskname).  All  tasknames  must  be  unique  within  one  of  the 
following  scopes: 

•  LOCALTASK  -  The  task  is  a  server  whose  name  is  only  known  within  the  loeal  CPU  OS. 

•  GLOBALTASK  -  The  task  is  a  server  whose  name  is  known  inside  and  outside  of  the 
CPU  to  a  group  of  logically  grouped  hosts  (tied  together  by  a  CIPLANSERVERHOST). 

•  WORLDTASK  -  This  is  similar  to  the  GLOBALTASK  exeept  that  the  server  name  is 
known  aeross  multiple  CIPLANSERVERHOST  groups.  CIPLANSERVERHOST  is  the 
system  environment  parameter  that  stores  the  host  eomputer  name  where  the 
CipNameServer  proeess  is  running. 

•  CLIENTTASK  -  The  task  is  a  client  whose  name  is  unknown  everywhere.  The  task  will 
have  an  unpublished  listening  port.  The  task  will  make  all  its  eonneetions  by  using 
netOPEN  (6)  to  a  server. 

2.1.2  Agent  Registry  Services 

Eimitation  from  the  CIP  interproeess  eommunieation  networking  serviees  arises  when  similar 
tasks  with  same  names  are  running  on  multiple  robots.  To  encompass  this  problem,  the  CIP 
Agent  Registry  Serviees  (6)  is  used.  The  Agent  Registry  is  an  idealized  database  that  holds 
information  regarding  the  serviees  that  all  registered  agents  offer  to  other  agents  in  the  network 
eommunity.  Agents  referenee  the  Agent  Registry  when  trying  to  find  the  identity  of  another 
agent  that  will  provide  a  needed  serviee.  Although  the  Agent  Registry  makes  no  guarantees  that 
a  reeommended  agent  is  eurrently  instantiated  on  the  network,  the  eurrent  implementation 
requires  the  agent  to  self  register,  and  therefore  the  actual  existence  of  a  partieular  agent  is 
probably  very  high.  In  theory,  the  agent  registry  funetion  only  helps  one  agent  find  the  identity  of 
another  agent  that  best  meets  a  serviee  requirement.  The  agent  AregServer  is  a  C++  proeess  that 
implements  the  registry  database.  The  registry  server  is  implemented  as  a  layer  on  top  of  the 
CIPNET  proeess  name  serviee  where  one  master  registry  exists  in  the  WORLDNAME  scope  of 
the  network  and  optional  slave  registries  ean  be  invoked  as  elients  to  the  master.  Each  slave 
registry  MUST  have  a  unique  agentName/hostName  identifieation  beeause  the  slave  registry 
agents  use  the  same  registry  elient  API  as  any  other  agent  in  the  system. 

2.1.3  Robot  Control  Software  Agents  Description 

The  following  paragraphs  deseribe  the  software  agents  in  the  system  and  their  functions 
(Eigure  1): 
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Figure  1 .  Network  controFdata  flow  diagram. 

Robot  Device  Controllers-Low-level  status  and  control  of  sensors  and  robot  mobility:  compass, 
global  positioning  system  (GPS),  sonar,  mobility,  pan  tilt,  sniper  detector,  moving  target 
indicator  Image  server. 

Robot  Servers  related  Agents 

•  RobotAgent  -  controls  the  robot  mobility  via  the  RWI  hardware  servers 

•  PanTiltAgent  -  controls  the  pan  tilt  device 

•  LocationAgent  -  provides  the  robot  position  (lat/long)  and  compass  heading 

•  Mti Agent  -  locates  and  tracks  moving  objects  in  a  sequence  of  images  from  a  stationary 
camera 

•  SniperAgent  -  listen  to  acoustic  event  on  IPC  Socket  and  send  control  command  to  the  pan 
tilt  server 

Gateway  -  Provides  fusion  point  between  controllers  and  Operator  Control  Unit  (OCU)  or 
Ground  Control  Station  agents 

•  gsAgent  -  collects  and  fuses  data  from  Robot  Device  Controllers  (except  for  MTI)  for 
analysis  and  display  by  various  OCU  station  agents 

•  RobotParserAgent  -  accepts  control  commands  from  OCU  agents  and  sends  commands  to 
appropriate  controller(s) 

OCU  Station  Clients  Agents  -  Provides  robot’s  status  display  and  multimodel  I/O  control 
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•  GsDiplay 

Displays  data  received  from  gsAgent 

Provides  keyboard  input  window  dialog  to  type  text  string  commands  and 
simple  menu  bar  graphics  user  interface  (GUI)  to  control  pan  tilt  and  robot 
mobility  via  the  RobotParserAgent 

•  Little  Joy  -  reads  joystick  and  sends  pan  tilt  and  robot  mobility 

•  MtiDisplay  -  receives  and  displays  images  received  from  MtiAgent 

•  RobotSpeak  -  uses  the  Microsoft  Speech  Engine,  receives  voice  commands  from 
microphone  and  sends  to  the  RobotParserAgent  to  control  the  pan  tilt  and  robot  mobility 

The  Multi-robots  control/data  flow  diagram,  shown  in  Figure  2,  showed  the  scalability  of  the 
ARE  robot  control  software  infrastructure.  It  also  showed  that  the  bottlenecks  could  happen  at 
the  RobotParserAgent  and  GsAgent.  This  should  not  have  any  impact  if  the  number  of  robots  is 
less  than  eight.  Future  implementation  will  be  concentrated  on  improving  the  design  to  allow 
multiple  copies  of  RobotParserAgent  and  GS  Agent  to  run  and  add  the  dynamic  routing 
connection  capability  from  the  OCUs  to  the  RobotParserAgents  and  GSAgents  based  on  the 
network  traffic  to  those  agents. 


Figure  2.  Multi-robots  control/data  flow  diagram. 

In  this  configuration  (Figures  3  and  4),  the  robots  are  interfaced  to  the  2-D/3-D  map  display 
modules.  The  2-D-CIP  maps  application  window  is  displayed  on  one  of  the  touch-sensitive  flat 
panels,  and  the  3-D-VGIS  maps  application  is  displayed  on  the  other.  This  set  up  provides  the 
capability  for  users  to  collaborate  in  selecting  control  waypoints  from  the  2-D/3-D  application 
windows  to  define  the  route  for  robots  to  perform  the  RSTA  operation.  Current  obstacle 
avoidance  capability  of  the  robot  is  limited  to  the  simple  guarded-motion  algorithm  from  RWI 
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Figure  3.  Autonomous  asset  eontroller  configuration. 


Figure  4.  Autonomous  asset  controller  diagram. 

using  sonar  and  laser  system  sensors.  Sophisticated  route  planning  and  reactive  behaviors  are 
currently  being  implemented  onto  the  robots  to  provide  better  autonomous  to  robots. 

2,2  Hardware  Architecture 

As  mentioned  previously,  the  testbeds  that  ARL  is  using  for  the  research  presented  in  this  paper 
are  COTS  robotic  mobility  platforms  from  iRobot  (Somerville,  MA)  outfitted  with  commercially 
available  RSTA  sensors.  ARL  is  using  three  ATRV-2  robotic  platforms  that  have  several 
limitations  for  our  testing  with  soldiers,  which  is  the  topic  of  this  section.  In  addition  to  the 
ATRVs,  we  have  an  Urban  Robot  that  can  “dock”  onto  the  ATRV,  and  are  currently  integrating 
Packbot  robots  from  iRobot.  These  two  smaller  robotic  platforms  came  out  of  the  Defense 
Advanced  Research  Projects  Agency  (DARPA)  Tactical  Mobile  Robotics  (TMR)  program. 
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We  have  developed  a  design  for  a  modular  robotie  sensor  platform  that  replaces  the  existing 
sensor  platform  for  the  ATRV-2  robotic  platform.  Our  design  addresses  many  of  the 
shortcomings  of  the  existing  platform  for  our  testing  needs  and  facilitates  experimentation  with 
U.S.  Army  soldiers  and  other  field  experiments.  We  have  designed  a  modular  hardware  design 
that  facilitates  changing  sensors  and  components  for  our  experimentation  with  soldiers  in  the 
field.  Additionally,  our  platform  resists  dust,  rain,  and  other  environmental  effects  that  the 
existing  system  doesn’t.  Some  of  our  testbeds  are  shown  in  Figures  5  and  6.  The  larger 
ATRV-2  robot  shown  in  Figure  5  is  outfitted  for  an  RSTA  mission.  The  sensors  in  Figure  5 
include  the  following;  visible  camera,  IR  camera,  laser  rangefinder  (LADAR),  weather  sensor, 
stereo  camera  pair,  sound  navigation  and  ranging  (SONAR),  GPS,  a  digital  compass,  and  an 
acoustic  array.  The  modular  design  also  considers  future  testing,  which  includes  different 
missions  like  a  logistics  mule,  communications  relay,  or  different  sensing.  In  addition  to  the 
sensors,  we  have  multiple  processors  onboard  the  robot  for  sensor  fusion  and  detection  as  well  as 
providing  services  to  the  thin  clients  on  the  LW  Systems.  We  are  currently  integrating  several  of 
the  RSTA  sensors  onto  the  Packbot  platform  shown  in  Figure  6.  These  sensors  include  an 
acoustic  array,  a  visible  camera,  and  an  IR  camera.  Additionally,  the  design  allows  for 
transporting  the  smaller  Packbot  robot  to  facilitate  mother  ship  experiments. 


Figure  5.  iRobot  ATRV-2  robot  with 

improved  modular  sensor  platform. 

The  original  iRobot  ATRV-2  was  not  designed  to  be  used  outdoors  in  adverse  weather  and  harsh 
environments.  Additionally,  it  is  not  as  modular  as  we  needed  to  rapidly  change  components  in 
experimental  environments  with  soldiers.  It  is  not  water  resistant  for  operations  in  the  rain  and 
snow.  It  was  also  not  protected  from  dusty  and  dirty  environments.  Both  of  these  shortcomings 
have  caused  computer  components  and  sensors  to  fail  during  previous  experiments.  The  past 
design  is  not  modular  and  is  currently  configured  for  an  RSTA  mission  with  an  8-microphone 
acoustic  array,  a  visible  camera,  an  IR  camera,  12  sonar  sensors,  3  CPUs,  1  wireless  LAN,  a 
video  transmitter,  a  GPS  sensor,  a  digital  compass,  and  a  driving  camera.  It  is  used  to  detect 
gunshots  and  loud  impulsive  noises  in  an  urban  environment  and  to  perform  image  motion 
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Figure  6.  iRobot  Packbot. 

tracking  using  both  cameras.  The  robot  has  been  used  at  experiments  with  U.S.  Army  units,  at 
DARPA  Taetieal  Mobile  Roboties  (TMR)  Program  experiments,  and  reeently  with  the  U.S. 
Army’s  LW  System  to  demonstrate  soldier/robot  interaction  and  experimentation. 

The  improved  modular  sensor  platform  presented  here  is  foeused  on  condueting  RSTA  missions, 
primarily  in  urban  environments.  The  present  design  is  modular  enough  to  accommodate  other 
sensors,  but  it  is  currently  configured  with  an  8-microphone  acoustic  array,  a  visible  camera,  an 
IR  eamera,  a  scanning  LADAR,  a  point  LADAR,  12  sonar  sensors,  3  CPUs,  2  wireless  LANs,  a 
video  transmitter,  a  GPS  sensor,  a  digital  eompass,  a  weather  sensor,  a  stereo  camera  pair,  and  a 
driving  camera.  This  design  ineludes  previous  functionality,  plus  the  ability  to  detect  and  track 
vehicles  acoustically  and  visually;  navigate  using  waypoint  navigation  as  well  as  teleoperation; 
aet  as  a  eommunieations  relay;  allow  smaller  robots  (Paekbots)  to  doek;  as  well  as  many  other 
advancements,  applieations,  and  capabilities.  This  platform  is  eurrently  being  used  to 
demonstrate  soldier-robot  interaction  with  the  current  and  future  LW  Systems  and  ARL,  Human 
Research  and  Engineering  Directorate  (HRED).  Additionally,  this  platform  will  be  used  during 
experimentation  of  multiple  robotie  physical  agents,  demonstrating  eollaborative  eontrol  and 
data  fusion.  Also,  experimentation  of  processing  and  eommunieations  on  small  robotic  systems 
will  be  condueted.  Eigure  7  shows  an  alternate  improved  modular  sensor  platform  design  being 
developed. 

In  the  future,  the  design  will  be  upgraded  by  simply  adding/exchanging  some  eomponent 
modules  or  by  exchanging  entire  mission  paeks.  The  modular  design  provides  the  ability  for  the 
ATRV-2  to  act  as  mother  ship  for  smaller  packbot  (and  ECS  soldier  unmanned  ground  vehicle 
[SUGV])-sized  robots.  For  example,  the  robot  can  recharge  depleted  batteries  on  smaller 
Paekbots  (inereasing  mission  duration),  can  carry  Paekbots  (increasing  mission  range),  can  fuse 
information  from  multiple  robots  (increasing  processing  capability),  and  can  act  as  a 
communications  relay/uplink.  Additionally,  the  design  is  flexible  enough  to  allow  the 
introduetion  of  a  module  that  can  launch  a  micro-UAV  and  receive  data  from  it.  The  design 
allows  for  a  module  that  ean  deploy  numerous  unmanned  ground  sensors  to  the  battlefield  or 
other  mission  loeations.  Furthermore,  the  modular  design  provides  the  capability  of  acting  as  a 
logistics  robot  (LOGBOT)  that  can  recharge  batteries  for  existing  soldier  needs,  like  a  platoon  of 
soldiers  wearing  EW  Systems  and  other  neeessary  battery  requirements.  The  design  allows  for 
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Figure  7.  Model  of  Modular  Platform. 

the  introduction  of  a  future  hybrid-electric  power  system  where  a  generator  is  added  to  the 
existing  batteries,  allowing  for  longer  mission  durations.  The  introduction  of  fuel  cells  is  another 
possibility  for  future  onboard  power  generation.  Future  planned  uses  include  mapping  the 
interior  of  buildings  with  the  robots  and  communicating  that  information  back  to  other  robots  for 
distributed  fusion  and  collaboration,  or  back  to  commanders.  Also,  a  communications  module  is 
under  development  where  the  robot  will  be  transitioned  from  an  RSTA  mission  to  a 
communications  relay,  and  several  robots  will  act  as  a  remote  distributed  antenna  array.  The 
future  introduction  of  a  chemical/biological  agent  detector  to  the  robot’s  suite  of  sensors  will  be 
used  to  keep  soldiers  out  of  harm’s  way.  The  docking  module  may  be  replaced  with  a  module 
that  deposits  unattended  ground  sensors  and  may  retrieve  them  (or  other  robots)  with  a 
retriever/manipulator  arm  module.  Additionally,  any  of  the  modules  can  stand  alone  or  be 
placed  on  other  platforms  by  just  applying  power. 


3.  Experimental  Results 


Here  we  discuss  two  experiments  that  demonstrated  the  architecture  presented  in  this  report. 
Results  from  field  experiments  conducted  at  Ft.  Knox,  KY  and  Ft.  Bragg,  NC  are  presented  here. 


3.1  Ft.  Knox,  KY 

The  first  experiment  that  we  will  discuss  occurred  in  May  2001  at  Ft.  Knox,  KY.  At  this 
experiment,  we  demonstrated  the  Scout  Warrior  concept.  We  outfitted  a  tank  commander  in  a 
Bradley  Fighting  Vehicle  with  a  modified  LW  System  to  control  the  robot  that  was  deployed  out 
of  the  Bradley  with  the  scout  soldiers.  This  experiment  and  demonstration  was  conducted  at  the 
Armor  Conference  with  the  LW  program  office  and  Exponent  of  Phoenix,  AZ.  Figure  8  shows 
the  robot  in  a  Bradley,  and  Figure  9  shows  the  Scout  Warrior  Team. 


9 


Figure  8.  Robotic  Scout  in  Bradley  Fighting  Vehicle. 


Figure  9.  Scout  Warrior  Team. 

LW  (7)  is  the  U.S.  Army’s  program  for  integrating  the  infantry  soldier  into  a  battlefield  digital 
communication  system  that  is  optimized  for  close  combat.  The  LW  has  several  subsystems:  the 
weapon,  integrated  helmet  assembly,  protective  clothing  and  individual  equipment, 
computer/radio,  and  software.  ARL  collaborated  with  Exponent  to  interface  the  LW  training 
system  with  the  ARL  robot  system  for  demonstration  at  Ft.  Knox. 

Exponent  provided  the  LW  map  display  server  software  with  the  modification  to  display  the 
robot  symbol  on  the  map  accordingly  with  the  robot  GPS  location.  Additionally,  Exponent  built 
the  Gatewayserver  that  receives  user  datagram  protocol  (UDP)  data  from  GsLW  and  MtilW  and 
sends  them  to  Exponent  groundstation  and  other  LW  Systems  for  display  (see  Figure  10). 

ARL  developed  and  modified  several  software  components.  The  gsLW,  which  accepts  data 
from  the  GsAgent,  filter  and  forwards  them  via  UDP  to  ExponentServerGateway.  The  mtiLW 
receives  and  displays  images  from  MtiAgent  and  transmits  image  data  by  either  copying  them  to 
a  bmp  file  and  sending  the  filename  on  to  a  UDP  channel  or  by  sending  the  raw  image  on  the 
UDP.  The  LwSim  receives  an  image  for  display  from  mtilw  on  the  UDP  channel.  LittleJoy 
reads  joystick  and  sends  pan  tilt  and  robot  mobility  commands  to  RobotParserAgent.  This  is  a 
modification  of  the  Joystick  program  to  support  a  smaller  joystick  on  the  LW’s  USB  port.  The 
Mobility/P anTilt  Graphic  User  Interfaces  -  sends  robot  pan  tilt  and  robot  mobility  commands 
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Figure  10.  LW  configuration  control/data  flow  diagram. 

from  simple  GUIs  displayed  on  the  LW  toueh  sensitive  tablet  display.  Four  types  of  UDP 
paekets  were  used  as  follows: 

•  Type  l(TraekPaeket):  robot  ID,  robot  longitude,  robot  latitude,  robot  heading 

•  Type  2(SniperPacket):  robot  ID,  sniper  longitude,  sniper  latitude,  sniper  heading 

•  Type  3(image  filename):  image  is  stored  in  e:\temp\mti*. bmp  and  the  filename  is  sent  to 
Exponent  Gateway  server  as  UDP  type  3. 

•  Type  4(image):  image  bitmap 

The  ARL/Exponent  integration  provided  the  enhaneed  eapability  to  LW  to  wirelessly  tele- 
operate  the  robot  and  eontrol  the  eamera  motion  from  a  safe  loeation.  The  robot  was  used  to 
wateh  an  area  of  interest.  Imagery  aequired  from  the  robot’s  visible  and  IR  eameras  ean  be 
viewed  on  the  enhaneed  LW  display  tablet  and  then  can  be  transmitted  back  to  the  ground 
control  station  and  other  LW  Systems. 


3.2  Ft.  Bragg,  NC 

The  second  experiment  that  we  will  discuss  occurred  in  July  2001  at  Et.  Bragg,  NC.  At  this 
experiment,  we  demonstrated  the  Robot  Warrior  concept  with  the  LW  system.  We  outfitted  a 
light  infantry  soldier  with  an  LW  training  system  to  control  the  robot.  Eigure  1 1  shows  the 
soldier  controlling  the  robot,  and  Figure  12  shows  the  Robot  Warrior  with  the  LW  fire  team. 

In  this  experiment,  the  configuration  was  essentially  the  same  as  in  the  Ft.  Knox  demonstration 
except  that  a  single  light  infantry  soldier  outfitted  with  an  LW  training  system  controlled  the 
robot.  The  soldier  was  able  to  control  the  robot’s  movement,  sensors,  and  communicate  with  his 
squad.  Due  to  processing  constraints,  the  soldier  controlling  the  robot  was  the  only  one  able  to 
see  what  the  robot  detected.  However,  the  architecture  supports  the  images  from  the  robot  being 
sent  to  all  of  the  squad  members,  and  this  capability  will  be  implemented  into  future  variants  of 
the  LW  System. 
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Figure  11.  Robot  with  LW-equipped  soldier. 


Figure  12.  Robot  with  LW-equipped  soldiers. 


4.  Conclusion  and  Future  Work 


The  system  architecture  presented  in  this  paper  demonstrates  the  multi-echelon  control  of 
multiple  robots  and  a  modular  hardware  approach  to  accommodate  experimentation.  Ongoing 
work  shows  the  control  of  multiple  robotic  platforms  from  a  soldier  wearing  an  LW  System,  and 
from  a  more  capable  (2-D/3-D  map  display,  processing,  and  communications)  C2  platform. 
Upcoming  field  experiments  will  test  the  control  of  up  to  five  robots  in  the  field  at  Adelphi,  MD, 
Blossom  Point,  MD,  and  at  Spesutie  Island,  Aberdeen  Proving  Ground,  MD.  During  these 
experiments,  we  will  use  both  single  soldier  and  C2  platform  control  in  the  field  of  the  software 
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described  in  this  paper  that  has  been  demonstrated  in  the  laboratory.  Also,  we  will  be  collecting 
data  for  ongoing  work  for  collaboration  between  several  robots  and  sensor  fusion  from  multiple 
points  of  view  (5,  9).  This  collaboration  includes  integrating  UAVs  and  Unattended  Ground 
Sensors  into  the  overall  system,  which  can  cue  the  ground  robots. 

Additionally,  we  are  currently  involved  in  integrating  the  control  of  ARL  robot  testbeds  with  the 
OFW  program  and  with  future  variants  of  LW  Systems.  During  this  integration,  we  will 
incorporate  voice  control  of  the  robots,  waypoint  control  of  the  robots  using  the  LW  map 
display,  tactile  glove  input,  and  integrated  soldier  weapon  control  of  the  robots. 

Future  work  also  includes  integrating  several  of  the  RSTA  sensors  from  the  ATRV  platform  onto 
the  Packbot  platform.  Specifically,  ARL  is  working  with  iRobot  to  integrate  acoustic  sensors,  IR 
imaging  sensors,  and  RSTA  processing  onto  the  packbot  (10).  The  ATRV  robots  can  then  carry 
these  Packbots,  and  mother  ship  (marsupial)  experiments  are  planned  to  continue,  including 
autonomous  docking  and  charging. 

Finally,  ARL  is  working  with  the  PM  Soldier  office  and  Natick  Soldier  Center  to  develop  a 
prototype  robotic  MULE  targeted  for  the  OFW  program.  The  desired  concept  is  to  apply  limited 
robotics  and  teleoperation  to  an  M-Gator  platform  with  LW  connectivity  and  interface.  The 
proposed  M-Gator  will  be  controlled  using  an  ARL-developed,  soldier-worn  universal  robot 
controller  that  integrates  weapon  control,  glove  control,  speech  control,  and  waypoint  control. 
The  M-Gator  provides  the  LW  System  advanced  processing  capability,  memory  capability,  and 
smart  battery  charging.  It  can  also  provide  a  LW  squad  with  water  purification,  equipment 
carrier,  communications  relay,  and  act  as  a  mother  ship  for  robots  (like  Packbots)  for  use  by  the 
LW  squad. 
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